Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1167

Internet Message Format | 1994-08-27 | 13.9 KB

Subject: GEM List
Subject:  Re: Gem List
Subject: Re: Gem List
Subject: Re: Digest
Date: Sun, 31 Jul 94 04:08 EST
From: "Daniel J. Hollis" <[e-mail]>
To: ems <[e-mail]>
Subject: GEM List
Message-Id: <90940731090809/[e-mail]>
Precedence: bulk

Subject:  Re: Gem List

Anonymous:
----------
> Any features which make the display confusing, overload the user with too
> many options to choose from, or simply wouldn't get used, yet it's
> included.

Then why include the option at all, then, is what you're saying.  That's a
poor attitude towards GUI libraries.  IMHO, the more options, the better.
Just make it so the options can be understood in plain English, and one
option sets a whole feel to the library instead of one option being something
piddly like turning sliders on or off in a window (active redraw)...

> The Germans seems to have this tendancy toward making the user interface
> as complicated as possible.  They will give the user too many options.
> Perhaps 90% was an exageration... perhaps not.

Sounds like you have something against German libraries.  I think they are
great, and they provide GREAT ideas for us AMERICANS to go by.

> I'm talking about abandoning the way GEM functions.  For example, the
> closer should not pop up a menu (except in circumstances where it's
> really useful, but let's not make a habbit of it).  This change in style
> will do nothing but confuse and frustrate the user because he has to
> contend with another dialog.

Then it makes no sense to argue about this.  GEM doesn't function in any
consistent way.  It functions the way YOU make it function.  Why would
a closer pop up a menu?  My library only pops up a menu if you hold down the
button on a closer.  If you tap the closer shut, it closes it.  I begin
to wonder if you received a copy of XAES without my permission...

> And too much stuff involving the background windows will also just be
> confusing.

Oh ghee, let's just abandon background windows altogether, then.

> I didn't say I wanted NO standards.  I want UNCONFUSING and SAFE
> standards.  I'd think you'd have realized that by now.

Sounds like you were bashing every standard we were talking about, so why
not just make your own standards and confuse EVERYONE else?

> I KNOW it's simple to do.  Even under normal TOS, my library already has
> the option to do that... for the dialogs anyway.  I use it for tool boxes.

Toolboxes are not the only place background windows should be enforced.  Make
it so that if a user creates a window with your library, they have the
option to use WF_BEVENT.  If they are not using the right TOS version, then
handle the WF_BEVENT bit yourself!

> If living in 1985 lets me get more work done faster and easier, then so
> be it.  I'm not one to hold back progress, but if this 'progress' is
> radical to the point that it only makes things more confusing and harder
> to work with, then I don't want it!

Why would making a dialog in a window be more confusing?  If background
activatable windows were confusing, Atari would never have put that option
into MultiTOS or FalconTOS.

> Well, I break my library down into a few seperate .C files and the
> programmer can pick which ones he wants.  I'm sure that's what most of us
> do.

Instead of making it so that the programmer has to go through your own code,
look around and say "Ah, that's what I want, but only this one function" why
would you do this?  Just create one MYLIB.LIB file, and include bindings,
and simple documentation (simple enough to show them how to write a program),
and you will be set.  Don't include the .C files.  It will make it so the
programmer has to fix your code if something is incompatible, and it will be
a waste of time for the programmer.  If I were in their shoes, I'd try to fix
the problem a few times.  If the problem doesn't get fixed by *simple* ways-
and-means, the library gets trashed.  Simple as that.

> I don't know if it's big.  I don't know what it does.  Let me put it this
> way... if mine does the same amount or more and it's smaller, than yours
> it too big.  We'll see.

That's a poor way of looking at it.  If one library does more than one other
library, that doesn't mean it's better.  You've gotta look at the code
itself, but then, I doubt I'm giving my code out, just my libs.

> I'm not LIMITING it to 50k.  Why don't you read it again?  I said, "...I
> doubt it will grow to more than 50k...."  This means it probably won't,
> but if it does, no biggie.  I'll have a good reason for it.  :)

Sounded like you were limiting it to 50K.  I simply read between the lines.

>> Ok, then use XAES. We allow you to drag/resize/scroll/close/etc windows in
>> the background under normal TOS, even TOS 1.0.
> How do you do this?  HOW?  You can't get anything other than WM_TOPPED
> messages to background windows under normal TOS.

Yes, you cannot get anything other than WM_TOPPED messages from background
windows under normal TOS. So what? You don't *need* anything other than a
WM_TOPPED message from a background window to do these things.

> Oh, but you're replacing parts of AES, aren't you.  Vector-stealing.
> Icky.  Isn't the exception stack frame different on the 68030 compared to
> the 68000?

Nope, sorry. I'm not sure how you came up with that assumption....

I'm sure if someone thought about it for about 5 minutes, they could figure
out how background windows can be done under TOS 1.0. I figured out how to
do it over a year ago.

No patching the AES, no vector stealing required. And it's *SIMPLE*.

Hint : The ability to handle background window gadgets (sizer, sliders,
       titlebar, etc.) is directly linked with the ability to click
       background buttons in dialogs.

About exception frames : Yes, 68000 and 68030 frames are different. So what?
It's *easy* to handle both frames, by the way. Let'em Fly traps vectors and
yet it works on all 680x0 systems (if you want to get technical.) What this
has to do with this discussion is beyond me, however.

> A LITTLE?  Are you kidding?  First I'm going to have to decode the file,
> then I'm going to have to translate the codes into what gets displayed,
> then I'm going to have to figure out where (and in what character space)
> to put them into my menus, then I'm going to have to scan my list every
> time the user presses a key, and on top of that, I'm probably going to
> have to uut up with some brain-dead method of figuring out which key is
> which because someone wants to use hardware scancodes for the Ctrl-Letter
> keys, which makes no sence because it's non-portable.

Just sounds like you're a lazy coder.  There is *nothing* hard about what
you just explained to me.  It's all a matter of sitting down and DOING it.
If you keep contradicting everything I say and saying it's not easy, or it's
impossible, then no one will even WANT to get your library.  Don't be a lazy
assed coder.  TRY something for a change, rather than coming up with excuses
to get out of everything before even trying it.

> Yeah, sure... and let's make the user spend 5 hours on install, 4 of
> which is for configuration, and the last hour is for copying from floppy
> all the code for all the features that the user turned off.

I don't think you read the message.  I didn't say to make it hard to install
either.  There should be a set list of standards in the installation
process which gets added on to APP_DEFS and GUI_DEFS (??) so that the options
are already there.  There's no *hours* of configuration, just load-and-go.
Ever heard of that word?

> And then when the user wants to use the program, he has to deal with
> XAES, your new user interface with all these new gadgets he's never seen
> before, and spend hours just figuring out how to use the program, and
> then when he wants to change a feature, he has to spend another hour
> tracking it down from all the countless other options you have burried
> somewhere.

Uh, sorry to disappoint you -- but those gadgets are configurable. You don't
want them? Then don't use them! XAES will default to 'normal' windows in
dialogs. Although the option is still there for power users for the new
gadgets. XAES doesn't *force* you to do anything. XAES is all about
*choices*, not being forced to do anything you don't want it to.

If you were to code with my library, you would find out immediately how easy
it is to code.

"new gadgets he's never seen before"?  Then why is Windoze 3.1 and Motif
selling so well? XAES uses alot of stuff from Motif and Windoze (only the
good ideas, not the lame assed ones.) Well, if the user has been living under
a rock for the last 6 years, they might not have had exposure to these "new
gadgets" as you call them.

> ute.  Very cute.  Ctrl-A is the only combination that I have ever hit
> accidentally that also caused me catastrophic problems.  Unintentionally
> selecting the whole document can cause anything from minor irritation to
> lost data, depending on the rest of the user interface.

Hmmm, I wonder what this "UNDO" key is for. Maybe it's there on the keyboard
just for looks...

> I am one of many people who have complained about Atari Works wiping out
> their documents when their little finger slips and hits Ctrl and A at the
> same time.

Then get rid of AtariWorks and quit complaining. Anyone who uses AtariWorks
deserves what happens to them :-)

> You do NOT assign dangerous options to key combinations that are
> FREQUENTLY accidentally hit.  I may be the only one on the GEM-List who
> has this problem, but there are countless others who also have this
> problem, and if the people on the GEM-List are so SHORT SIGHTED that they
> cannot fathom that this might happen to someone, then I start to wonder
> what other judgement errors they will make in the future, causing just as
> much frustration for people and harm to their data.

I assign internal keycodes for my library.  If they want something done, they
would have to FORCE to it themselves for the window on the screen.  The only
way they can do anything is to hit ALT-CTRL- and a key combination.  That's
not something you hit just by accident.  Besides, I've never hit CTRL-A on
accident yet, and I use QED and Rufus all the time.

-- Ken Hollis (Bitgate Software)
-----
Subject: Re: Gem List

Anonymous:
----------
>> Nobody should *ever* send keypresses to anything but the window under
>> current focus. It is *incredibly* confusing to do otherwise. Just flip
>> this option on in some X11 window manager and you'll learn really damn
>> quick to hate it (as well as auto-window topping.. this is a totally
>> STUPID idea!)
>I never thought I'd say this, but I actually agree with you here :)

I think it is safe to say that most of us agree with this.

> But there is a standard for what windows look like and what the gadgets do.
> Yes it depends on TOS version but people only use one TOS version and with
> that all their applications _except_those_written_with_your_library_ will
> look and feel the same.

Have you used WinX?  They have different window gadgets, and yet, I don't
hear anyone complaining.

-- Ken Hollis (Bitgate Software)
-----
Subject: Re: Digest

?!?!?!:
-------
> If you allow clicks in background windows then it will not be consistent
> with other applications. Topping windows on all clicks in them may not be
> desirable but it _is_ consistent with existing GEM programs and with
> programs for the mac and mswindows. As for intuitive, since keystrokes
> obviously go to the top window only, why not buttons. It isn't intuitive
> if button events sometimes top a window and sometimes activate a button
> depending on where they are. I can't see anything wrong with GEM on the
> ease of use front and as for ease of programming - it's pretty bad, but
> have you tried mswindows?

What the HELL are you thinking?  Almost all programs that run with MultiTOS
have background window settings in one way or another.  Face it.  You're too
*L A Z Y* to even code this.  *TRY* it before you open your mouth and let out
senseless hot air.  I can safely say that you don't have a CLUE as to what
you are talking about.

You are talking about abandoning MultiTOS's standard of WF_BEVENT and the
Falcon's WF_BEVENT window clicks altogether and forming your own little party
that background windows don't exist and are useless.  Most of us here agree
that Background Windows are extremely useful, and are almost essential.

To answer your question...  Yes.  I have tried MSWindows and I hate it. In a
lot of ways the GUI is more primitive than GEM, however there are also a lot
more STANDARDS than there are in GEM (where there are virtually none). And
yes I know lots of people break the rules on MSWindows, but then lots more
people follow them simply because of standard libraries like OWL (Borland)
and ObjectWindows (MicroSoft) and the like.

> Which version? I've seen the first 4.1 beta and it is almost as fast as
> single tasking versions of TOS, although it doesn't work properly on the
> falcon.  Apparently the second beta is faster still.

I would have to see this to believe it.  MiNT itself is slower than snot.
Put the new AES on top of it and things really go downhill. If you'd like to
prove me wrong, send a copy of this "almost as fast as single tasking
versions of TOS" MultiTOS to [e-mail].

Better yet, do some benchmarks and give some *hard* facts, numbers that
can be *duplicated* by anyone. Try something like GemBench and Speedometer
and post the numbers. Without hard facts, I'll simply consider that claim
hearsay. I'd love to have you prove me wrong, since it would indicate that
Atari got their head out of their .... with this new MultiTOS (at least in
terms of speed, not usability -- that is a completely different issue.)

> There is almost no overhead due to MiNT. On average the slowdown is
> negligible and many things such as memory allocation are a bit faster.

This is obviously the talk of an experienced MiNT programmer.

Some people would consider 8%-16% slowdown "almost no overhead", but I'm
not one of them. 1% to 2% is "almost no overhead" to me. But not 8%-16%.

-- Ken Hollis (Bitgate Software)